Current security module content management models require a content provider to trust the parties involved in the production, issuance, management, content delivery, and usage of a security module before communicating content with the security module. Additionally, the content provider must trust that the end-to-end communication with the security module is never transmitted to a security module production entity having security module keys, since this could lead to the disclosure of content provider keys and the content they protect. Also, the content provider must trust that third parties having security module keys do not misuse or disclose their keys. These trust requirements exist regardless of whether the content provider is directly delivering content to the security module and whether the content is delivered in real-time to the security module.
A content provider must trust a security module manufacturer or issuer to protect and not misuse, substitute, or disclose to other parties the content provider's transport keys. Also, the content provider must trust the security module manufacturer or issuer to load the content provider's keys on the intended security modules with the intended configuration.
If a third party authority (e.g., multiple operating system key management authority (MULTOS KMA)) delivers some content provider key material to the security module manufacturer or issuer, then the content provider must fully trust the third party authority to distribute the correct key material and derivatives. The content provider must also trust the security module manufacturer or issuer to not misuse or substitute the distributed key material. If any party fails to enforce its responsibility, then the content provider will not derive the benefit expected from the security module and will not be aware of a security incident that may occur.
In addition to the above trust issues, there are specific weaknesses in the current device content management models that put the security of the content provider service at risk, particularly when the content provider does not have direct access to or full control of the communication channels transporting content to or from a security module. For example, with security modules equipped with GlobalPlatform, a content provider does gain cryptographic control over a security domain when importing a wrapped security domain key set that it exclusively owns, using an initial domain key set. The initial domain key set is shared by the content provider and a third party having prior access to the security module for the purpose of installing the initial key set. The content provider then deletes the initial key set. This is called a security domain possession operation. However, when the content provider does not have direct access to the security module, then the GlobalPlatform key exchange protocols do not protect the content provider from a traitor or negligence from the parties having direct access to the communications including the wrapped content provider key set. Specifically, the content provider key set can be obtained in plain text form by processing the communication logs including the wrapped keys (and secure channel establishment protocol) with a p11 hardware security module (HSM) hosting the shared initial key set.
In another example, with security devices equipped with MULTOS, the need to trust a third party is even more explicit since the content provider entirely relies on the key management authority (KMA) and issuer to provide content loading certificates. In addition to the trust requirement on the KMA, if any party employee or facility is at risk, the content provider assets are at risk.
In addition to the above mentioned issues, when a content provider, which has no direct access to a security module, wants to obtain assurance that a unique private asymmetric key or secret symmetric key is located on the security module and can be used to secure further communications between the content provider and the secure module, the key should never be accessible from other organizations with other keys on the security module, such as security. module manufacturers or service bureaus. In particular such other organizations should not be able to process communication logs with their own cryptographic material and discover the key. But the content provider does not produce the final protected security module commands, and relies on another entity to establish the logical communication and forward the content to the security module and corresponding responses from the security module. It has no other means than submitting content and receiving security module responses to verify that the security module is genuine.